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Abstract 


This  final  report  is  intended  to  be  a  summary  of  the  research 
on  Natural  Language  Data  Base  Query  performed  at  Dartmouth  College 
supported  by  the  Office  of  Naval  Research  since  1973.  It  has  been 
the  goal  of  this  research  to  determine  a  minimal  set  of  techniques 
sufficient  to  provide  a  practical  natural  language  capability/  for 
lata  base  query.  This  reoort  summarizes  the  basic  requ irements  for 
such  a  capability  and  suggests  techniques  for  meeting  these 
requirements.  As  such,  this  report  is  in  effect,  a  spec  if icat ion 
of  tne  minimal  functionality  for  a  practical  natural  language  data 
base  query  capability. 


ch  e  a  *  ► 

U  ~i  h  n  o  ■ 

;.)  U  M  M  O 

r*  B  r>  V)  9 

w  J  }  « 

►'1  o  >-*  1  w 

f  ••  £  *  C4 

i-3  j  o)  ;ju  o 

v  <i  2  3 

c+  ®  R* 

h>  Q>  M  >34 

O  O 

3  i  ** 


Pa  ie  2 


I nlroduction 

rthen  research  under  tills  contract  began  in  1971,  the  state  of 
the  art  in  practical  natural  language  data  base  query  was 
essentially  non-existent.  All  of  the  then  existing  research 
systems  (and  many  of  today's  systems)  were  semantical  Jv  Mnited  to 
a  single  domain  of  discourse.  The  primary  requisite  of  a 
“practical"  query  capability  is  that  it  he  "application 
independent" .  Achieving  this  application  independence  requires  a 
fundamental  commitment  throughout  the  design  of  the  system.  It  is 
encouraging  to  see  that  the  research  community  as  a  whole  has 
started  moving  in  this  direction. 

This  report  consists  of  a  summary  description  of  the  minimal 
requirements  for  a  practical  query  capability.  The  techniques 
developed  to  meet  these  requirements  an*  nr  mill  •<•.!  Into  lh  >  rmn 
lajor  components  of  operation  that  make  up  the  nrocessing  cycle  of 
a  repinst.  There  components  are  the  lexical  analyzer  (the 
;c  inner),  the  syntactic  analyzer  (the  parser),  the  .data  base 
structure  analyzer  (the  navigator)  and  the  data  processing  module. 
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The  L^xinl  Am 1  yzer  —  The  Scanner 

The  basic  function  of  the  scanner  is  to  determine  what  the 
individual  word's  or  tokens  are.  The  scanner  breaks  the  input 
stream  into  a  sequence  of  tokens.  A  modification  of  the  finite 
automaton  scanner  used  in  compilers  is  sufficient  for  this  task, 
lhe  modifications  are  required  to  deal  with  phrases  and 
recognition  of  special  numeric  tokens.  Phrases  such  as  "Vice 
President"  or  "lew  York"  must  he  recognized  as  single  tokens  even 
though  they  contain  a  space.  Mtimericnl  strings  such  as  "LiO/gi/31" 
must  be  recognized  as  a  single  token  (representing  a  date)  whereas 
■'1/3"  must  be  reconized  ns  three  tokens  representing  "one  divided 
ay  tnree". 

Scanners  with  these  capabilities  are  commonplace  among  A I 
natural  language  systems.  The  most  common  pitfall  is  to  imbed 
spelling  detection,  or  worse  yet,  spelling  correction  within  the 
scanner,  both  spelling  correction  and  spelling  detection  require 
advance  knowle^e  of  all  words  that  can  be  employe'4  by  users.  This 
is  prohibative  in  a  domain  independent  approach,  since  this  set 
of  words  must  clearly  contain  all  the  words  in  the  data  base, 
Therefore,  the  scanner  must  accept  words  about  which  it  knows 
nothing  —  which  could  be,  of  course,  potentially  misspelled 
words.  The  detection  of  a  spelling  error  is  best  made  as  part  of 
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i ho  oost  mortem  when  a  qnntftncn  f i  1  *=;  to  ho  understood  bv  the 
system.  This  approach  satisfies  the  domain  independence  criterion 
is  well  as  allowing  valid  requests  with  no  spelling  prros  tint 
perCa  in  to  data  values  not  actually  in  the  data  hasp  to  be  handled 
properly. 


'ilia  Syntactic  Analyser  —  The  Parser 

The  parser  is  the  heart  of  the  natural  language  component  of 
the  system.  Its  role  is  to  syntactically  relate  the  components  of 
the  request.  This  orocess  drives  the  construction  of  the  semantic 
structures  that  represent  the  meaning  of  the  request.  There  are 
several  computing  paradigms  for  natural  language  parsers.  In  the 
early  part  of  our  research,  we  successfully  employed  a  top-down 
context-free  parser.  Later  we  switched  to  an  Augmented  Transition 
detwork  parser  (ATI),  de  feel  there  are  several  advantages  to  the 
ATM  approach  that  make  it  far  more  convenient  to  use,  although 
successful  context-free  parsers  could  be  built  as  well,  decently 
several  new  parsing  schemes  have  been  reported  in  the  literature, 
so  that  it  may  well  be  the  case  that  the  AFII  technology  is  now 
dated.  However,  it  seems  clear  that  the  choice  of  parsing 
algorithm  is  less  important  than  the  mechanism  by  which  the  syntax 
controls  the  generation  of  the  required  semantic  structures. 
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The  definitive  problem  of  this  type  is  tint  of  ambiguitv. 
several  distinct  ‘vr-iant  ic  representations  Must  be  generate!  from  a 
single  input  strina.  The  difficulty  here  is  not  how  to  do  it,  hut 
now  to  limit  tha  Generation  of  too  many  interpretnt ions.  Many 
researchers  have  cnosen  to  limit  the  parser  to  generating  only  one 
interpretation  and  stopping.  This  approach  makes  the  decision  o* 
which  parse  to  pursue  a  very  critical  one.  It  also  makes  dealing 
with  truly  ambiguous  requests  very  difficult. 

Our  recommendation  is  to  solve  the  problem  from  the  other  end 
of  tne  spectrum  by  non-deterministica liy  generating  all  possible 
interpretations .  ibis  transforms  the  issue  fron  one  of  trying  to 
decile  on  a  relative  basis  which  of  two  partial  parses  looks  more 
promising,  to  one  of  trying  to  decide  on  an  absolute  basis  which 
of  two  comolete  parses  is  more  meaningful.  There  is  also  a  oroblen 
of  efficiency  in  roping  with  the  potential  exponential  number  of 
interpretations.  It  should  be  clear  that  decisions  made  on  an 
absolute  basis  after  the  parse  should  be  more  accurate  than 
decisions  made  on  a  relative  basis  during  the  parse.  The  effects 
of  tne  remaining  portion  of  the  input  have  had  a  chance  to  imnaot 
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Uio  iecision  in  th '  former  cnss,  hut  not  in  the  latter.  However, 
the  problem  of  exponential  growth  must  be  -innlt  with  very 
carefully.  Fortunately  it  seems  that,  at  least  for  natural 
language  query,  this  can  he  dealt  with  by  tuning  the  parser  to 
reduce  the  non-determinism.  Fortunately  the  length  of  thp  inout  is 
usually  very  small  (less  than  20  tokens)  and  the  number  of 
incisions  is  ''reasonably1'  small. 


binding  Values  to  Fields 

One  type  of  ambiguity  that  arises  frequently  in  data  base 
queries  is  that  of  choosing  the  field  to  which  a  given  value  is 
related.  Most  research  systems  solve  this  problem  with  dictionary 
definitions.  This,  of  course,  is  clearly  a  violation  of  domain 
indeoendence  since  it  requires  enumerating  all  unique  data  base 
values  in  the  lexion.  Our  approach  has  been  to  dynamically 
determine  this  from  indices  maintained  by  the  DBMS.  In  addition 
to  this,  we  allow  three  levels  of  strength  in  defining  'lata 
values  in  the  dictionary.  They  can  be  tightly  bound,  weaklv  hound 
or  unbound.  This  allows  for  sufficient  generality  at  the  same  time 
it  permits  definitions  that  could  limit  the  non-determinism. 
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ligh-Level  Semantic  Fntities 

Another  important  component  in  the  relating  of  .syntax  to 
semantics  is  the  ability  to  deal  with  entities  that  themselves 
imply  a  significant  semantic  structure.  This  involves  both  complex 
definitions  in  the  dictionary,  as  well  as  the  ability  to  d(=a] 
wit. i  these  definitions  in  the  parser,  examples  of  this  would  he 
terms  like  "bachelor"  or  "profit  margin".  The  first  specifies  a 

complex  description  whereas  the  second  specifies  a  formula  for 
calculating  profit  margin  from  other  entities  that  are  more 
directly  available.  It  is  of  critical  importance  for  a  natural 
language  system  to  be  able  to  deal  with  such  terms  directly, 
rather  than  forcing  the  user  to  continually  define  them. 


Pronouns 


Another  type  of  word  that  implies  a  substantive  holy  of 
semantics  is  the  nronoun.  fhe  distinction  here  is  that  the 
‘'meaning"  of  the  pronoun  is  not  to  be  found  in  the  dictionary  hut 
in  the  context  of  the  dialog.  Tn  addition,  there  may  be  some 
ambiguity  that  arises  in  determining  what  the  pronoun  refers  to. 

A  wide  variety  of  solutions  appears  in  the  literature  for  this 
problem.  Our  approach  is  to  maintain  two  context  registers 
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:  m  Li  in  in: .  the  semantic  s  truclures  of  orevious  jt  i  r»r-  i  r*  •=; .  t)n°  the 
previous  request,  the  other  is  the  request  tint  the  previous 
request  my  Vivo  roforroi  to.  In  addition,  i  ntrn-e=>ntent  i  a  I 
irnnuin  references  iro  also  allowed. 

.n  have  found  this  approach  to  be  sufficient  for  resolving 
the  vast  majority  of  pronoun  rofer°nc es  in  data  has r  queries, 
including  the  difficult  sequencet  “.that  is  the  maximum  seism  in 
Sissouri?"  "nho  earns  it?".  Contrary  to  popular  belief,  thR 
pronoun  "it"  dons  not  just  rfif nr  to  the  answer  of  the  first 
request.  If  it  did,  the  second  request  would  (generate  ell  oeopl  ° 
mrn  in j  that  salar/,  even  those  outside  ’<iegour-i. 

Ambiguous  pronoun  references  ore  dealt  with  in  the  sa  ve  wav 
is  other  ambiguities.  All  of  the  possible  mferents  are  considered 
end  non-determini  t  ic  interpretations  are  created  for  eecli 
possibility.  These  interpretations  are  then  co  i pored  on  a  global 
basis  later  along  w i 1 1 »  other  interpretations  created  bv  other 
cypes  of  ambiguity,  an  have  found  a  "search  logic  optimizer"  to  bo 
invaluable  in  weeding  out  iindesired  interpretations  created  by 
improper  pronoun  references.  The  optimizer  detects  the  logical 
contradictions  that  often  get  created  in  this  way. 
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one  for  :il  i-' ''  thit  fo  * *i  rrrnp  into  natural  Inoouaie  'ht-i  Lien 
Itiorles  is  that  of  nri  tin*  lie  ex  ore  ss  ions .  de  ,nv(>  fount  tho 
"recurs ive  descant"  for'.  1  lanquaoe  oonroach  for  norsinj 
arithmetic  exur  ;<^s  ions  to  'op  coup  lete  ly  cons  i  stent  with  Llip  Vpl 
;ra  ii  iir.  Howover,  certain  non-form#  1  form1?  of  ori  th  net  in 
■repressions  mnr  in  natural  lanouane  queries.  For  example*  "Mow 
air  i  Is  >is  r>|or  in  '  hi*  comni as ion?"  Here  wo  see  "an!"  used  as 
,liii  ( .(Orion's )  k.  i  the  ironoun  "his"  brenkinj  up  the  nuarand- 
jperator-operan J  sequence.  def  inements  to  the  baeir  recursive 
loscenl  aj preach  ere  required  to  deal  with  these  probiens. 


ueeannse  Hour  is  ties 

i.e  hove  found  several  heuristics  necessary  in  determining  the 
irons r  resr,onqe  for  a  given  query.  These  ere  primarily  iue  to  the 
inform.nl  phrasing  of  queries  that  occur  in  noturn l  lanuunoe. 

Jften  users  Mo  not  explicitly  nsk  to  he  given  information  tint 
they  quite  obviously  need  to  interpret  the  on.swers  end  quite 
rightfully  expect  the  system  to  provide.  For  exnmple,  the  request 
"Print  the  salary  of  Smith  and  Lawler"  implies  the  printing  of 
name  even  though  o  literal  interpretation  would  not  print  it. 
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'fit:  .out  pr  in  l  in  i  in  »  na.ier  as  -n  })  is  the  'nl'ifins,  ii  -<ero  <7 
impossible  for  tli  o  ns<»r  to  rioter  ■  in-->  which  sal  1  p.<  j  in-  with  which 
nr1'’*. 

oimilnrly,  natural  Intviunio  rn  |uosts  <:  ir.  tri  i!«r  rather  s  i  I  I  v 
’•as  innies  if  they  iro  intorpre  Lo.-l  too  liter  ally.  i  j  .-jnnry  “  /ho  i s 
viiui?*'  i  1 )  us  irate  ;  th  i  s  point,  it  the  nysto.i  wur^  to  oeohani  m  1 1  v 
iiUi[>nt  *'  who"  .as  in  indication  to  print  nano,  it  wm  1 1  i  racoon  1 
'*  -j:.i  i  th 14  to  the  request.  i.'lonr  l'/i  heuristics  ciust  be  nmnl  oye.  I  to 
letoct  such  situations  vi>-  to  determine  whn t  the  proper  response 
iliouli!  On.  The  activation  of  such  heuristics  must  u  i  t  i  e* -1  In  ly  be 
u nd-ar  user  control,  otherwise  the  system  rr. -> v  he  perceived  as 
./verhmring  since  the  user  loser  the  ability  to  precisely  control 
the  response  in  those  situations  where  it  is  important  for  the 
. -'st.  mi  to  !o  exactly  what  it  is  t  ol  l. 
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The  Navigator 

After  the  query  is  nnrserl,  the  semantic  structure  must  he 
projected  onto  the  database  scneme  resulting  in  a  strategy  for 
extracting  the  desired  information  from  the  database.  The 
lifficulty  of  the  navigation  problem  can  range  from  trivial  to 
arbitrarily  complex  depending  on  data  model  employed  by  the  OP  hj 
and  how  well  the  given  data  base  is  organized. 

For  single  flat  file  organizations,  navigation  is  at  its 
simplest.  But  even  for  single  flat  files ,  difficulties  can  arise 
if  the  file  was  created  by  flattening  out  a  hierarchy  or  a 
network.  In  these  cases,  the  notion  of  a  record  corresponding  to  a 
real  world  entity  is  lost.  Hence  the  navigator  must  take  advantage 
of  the  fact  that  the  file  was  originally  non-flat  to  construct  the 
proper  means  of  access  into  the  file. 


For  the  more  structured  data  models  such  as  relational, 
network  and  hierarchical,  the  naviuatlon  process  t.  Une  <m\  iron l 
importance.  Determining  the  proper  entry  point  into  the  structure 
as  well  as  the  proper  linking  relat ionshins  can  critically  affect 
the  contents  of  the  final  response,  not  to  mention  the  impact  on 
efficiency.  In  this  regard,  the  relational  model's  greatest  asset 
is  its  closed  form  expression  of  a  query.  This  makes  it  at  least 
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possible  to  express  nnviqacion  in  a  high-level  language  like 
SEQUEL.  For  hierarchies  and  networks  no  such  closed  form 
expression  is  user!  by  the  DR'iS  and  therefore  it  is  impossible  to 
express  navigation'll  choices  without  resortino  to  a  procedural 
representation.  This  is  the  essence  of  the  reason  why  no  pood  htgh- 
level  query  lanjuaqes,  even  of  a  formal  nature,  exist  for  network 
and  hierarchial  DR MS's.  Some  intermediate  level  renresentation  is 
clearly  needed  here. 

Even  for  the  relational  systems  we  have  not  been  uniformly 
satisfied  with  SEQUEL  as  an  intermediate  language,  fhe 
navigational  linkaie  is  specified  in  an  unduly  intricate  fashion, 
and  the  functionality  is  incomplete.  This  latter  point  is 
indicative  of  the  fact  that  much  of  SEQUEL'S  power  is  misdirected 
in  terms  of  the  needs  of  a  naive  end  user  of  a  natural  language 
system,  at  least  in  terms  of  our  experience .  Whereas  SEQUEL 
provides  no  assistance  in  answering  many  of  the  difficult  natural 
language  requests  we  encounter,  its  power  in  intricate  cyclic 
navigation  is  too  subtle  to  he  useful  in  a  natural  language 
setting. 
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Mnviont ionnl  Optimization 

Another  aspect  of  navigation  is  query  optimization.  The 
navigational  choices  made  have  a  profound  effect  on  the  efficiency 
of  generating  tne  answer,  hut  even  when  dealing  with  a  single 
relation  (or  a  single  flat  file  database),  there  is  a  significant 
amount  of  query  optimization  that  can  be  done.  For  example, 
questions  asking  from  the  maximum,  the  minimum,  or  unique  listings 
can  be  answered  directly  from  the  DBMS  indices  if  they  are 
available.  These  optimizations  can  change  a  several  minute 
response  into  an  instantaneous  response.  These  kinds  of 
optimizations  require  knowledge  of  how  the  data  is  going  to  be 
processed  after  retrieval  as  y/ell  as  knowledge  of  and  access  to 
the  DBMS  indices. 

Knowledge  of  the  DBMS  indices  is  also  a  critical  factor  in 
navigation  because  it  determines  how  long  the  DBMS  will  take  to 
respond.  Clearly  we  want  to  optimize  the  work  done  by  the  DBMS  and 
prefer  to  generate  requests  that  make  use  of  indices  or  hash 
coding  rather  than  file  pass  searches.  Rut,  given  the  variety  of 
ways  in  which  DBMSs  behave  on  mixtures  of  keyed  and  non-keyed 
searches,  it  is  clear  that  the  interface  must  have  its  own  ability 
to  perform  the  functions  of  searching  and  sorting.  There  is  a  nice 
meshing  of  these  functions  that  makes  it  possible  to  avoid  any 
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j  1  ■: ii  restrictions  in  this  ar«a  and  at  the  same  time  gives  tlie 
interface  control  of  the  situation  so  that  expensive  requests  can 
he  trapped.  In  general,  once  the  DBMS  gets  control,  the  user  must 
wait  until  the  DBMS  has  finished  processing  the  request,  which  mav 
oe  quite  a  while.  By  selectively  sharing  some  of  the  searching  and 
sorting  work,  it  is  possible  to  maintain  control  and  warn  the  user 
when  things  get  exoensive. 

This  flexibility  is  achieved  only  hy  added  complexity.  Not 
only  must  the  interface  have  the  searching  and  sorting 
funct iona] ity  hut  it  must  also  be  prepared  to  represent  the 
partitioned  workload  and,  of  course,  compute  the  partition  that 
will  effect  the  greatest  efficiency.  With  some  DBMSs,  this 
capability  is  only  an  efficiency  ootion.  With  other  DBMSs  that  do 
not  support  non-keyed  searching  or  sorting  at  all,  this 
capability  be cotes  critical  in  terms  of  being  able  to  answer  the 
request  at  all. 


security 

Another  aspect  of  the  navigation  problem  is  how  security  is 
taken  into  account.  It  is  clear  that  for  naive  end  users  of  a 
natural  language  query  system  that  security  from  unauthorized 


access  is  a  critical  issue.  Our  original  hope  in  this  regard  was 
chat  we  could  merely  relv  on  the  DI'.'IS  subschema  to  provide  the 
necessary  security.  Unfortunately,  we  found  the  oranularity  of  the 
subschema  security  to  be  too  large —  i.e.  access  is  granted  on  a 
field-by-field  basis.  This  is  fine  for  application  programs  but 
too  restrictive  for  data  base  query.  He  have  proposed  that 
security  also  be  defined  on  a  record-by-record  basis  so  that  a 
user  might  have  access  to  certain  fields  only  for  a  specific  set 
of  records. 

The  implication  of  all  of  this  on  navigation  is  that  the 
navigational  choices  made  by  the  system  must  be  a  function  of 
■/hat  data  is  available  to  the  current  user.  For  some  users, 
without  access  to  all  relations,  this  may  require  less  direct 
paths  than  would  otherwise  be  required.  It  is  up  to  the  navigator 
to  find  the  best  path  to  relate  all  the  necessary  data  without 
violating  any  of  the  security  constraints  along  the  way. 

The  final  issue  related  to  navigation  is  one  that  is 
currently  unresolved  at  this  time.  This  issue  is  the  mechanism  by 
which  the  parser  communicates  to  the  navigator  the  explicit 
"relationship"  information  that  the  user  included  in  the  request. 
In  general,  the  navigator  must  be  prepared  to  work  in  the  absence 
of  such  information  making  use  of  predefined  "natural  paths". 
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However,  in  those  coses  in  which  the  user  wishes  to  override 
the'se  predefined  oaths  by  explicitly  mentioning  another 
relit ionship,  the  system  must  be  prepared  to  act  accordingly.  For 
example,  in  a  database  of  professors  and  students  related  by  hoth 
a  "teaches"  and  an  "advises"  relationship,  the  two  requests  "Uhn 
are  Professor  Harris'  students?"  is  different  in  a  navigational 
sense  from  "Hho  are  Professor  Harris'  -advisees?"  or  "Who  does 
Professor  Harris  a  Ivise?"  It  is  clear  that  for  this  simole  case 
the  use  of  the  word  "advises"  or  "advisees"  indicates  to  the 
navigator  which  relationship  to  employ.  Put  in  more  complex  cases 
where  the  same  two  relations  must  be  .joined  more  than  once  in  a 
request,  it  is  not  clear  that  all  such  relationships  should  he 
controlled  by  the  explicit  use  of  one  relationship  words.  Of 
course  if  not  all  such  relationship  choices  are  impacted,  then  we 
must  decide  which  ones  are  and  which  ones  are  not,  presumably  on 
the  basis  of  the  original  syntax.  However,  at  this  point,  it  is 
not  clear  that  English  syntax  could  (or  even  should)  provide  this 
kind  of  information.  This  remains  an  open  issue  at  this  point  in 
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ttiB  Main  processing  an  I  Forma ti  irn  .Module 

After  a  query  is  processed  by  the  DfvhTJ  'in* f  additional 
searching  or  sorting  is  performed  by  the  interface  itself,  we 
eventually  arrive  at  a  single  temporary  re  1  a c ion  that  answers  the 
user's  request.  This  data  still  must  he  processed  to  provide  the 
user  with  the  information  summ  ir  ized  or  formatted  in  the  desire! 
tiny.  On  the  one  hand,  this  kin-'  of  data  processing  seems  vnrv 
commonplace — co  pouting  subtotal  s ,  formatting  repo  rts,  etc.  On  the 
other  hand,  this  module  would  ideally  he  on  on!.!  e  of  carrying  out 
an  arbitrary  sequence  of  process  inn.  In  this  i ase  it  becomes  the 
Hito'fiatic  programming  problem,  hone  interne  -11  ••  le  level  of 
capability  is  sought. 
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The  placement  of  various  functions  rush  •  -  total,  minimum  and 
maximum,  etc.  ran  often  lie  in  either  tne  IH.  if)  nr  in  the  interface. 
1'hls  represents  another  example  of  how  the  workload  ran  be 
shared.  Similarly  the  data  process  ina  module  mu-.t  wotk  ini  imately 
with  other  aspects  of  the  interface  that  maintain  the  pronoun 
context.  This  is  true  because  it  is  not  until  the  end  of 
processing  the  data  that  we  really  know  all  the  contexts  to  which 
subsequent  pronouns  might  refer.  It  is  certainly  conceivable  that 
some  processes  will  restrict  even  further  the  set  of  records 
iisplnyed  for  the  user  on  the  basis  of  some  arbitrary  predicate. 
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From  the  user's  point  of  view,  a  pronoun  is  likely  to  refer  onlv 
to  the  set  of  records  actually  printer).  Since  the  interface  has  no 
knowledge  of  whit  the  arbitrary  predicate  is,  it  would  be 
impossible  for  it.  to  generate  a  high- leva  i  represent"!  L  ion  of  what 
subsequent  pronouns  nay  refer  to.  The  implications  of  this  are 
quite  profound.  Since  the  system  no  longer  has  a  high-level 
representation  of  the  oronoun  referent,  it  becomes  difficult  to 
“echo"  the  meaning  to  the  user  or  to  even  tall:  shout 
interpretation  in  clarification  dialogs. 

On  the  positive  side,  the  low-level  representation  of  a 
pronoun  reference  that  is  necessitated  by  all  this  can  speed  tin 
all  pronoun  references,  fhis  is  particularly  noticeable  when  the 
result  of  a  non-key ed  search  is  referenced  by  a  pronoun.  If  only 
a  high-level  pronoun  represents l ion  is  maintained  than  the  costly 
search  must  be  recomputed.  If  both  a  high-level  and  low-level 
pronoun  representation  is  maintained,  then  the  system  can  describe 
the  query  to  the  user  with  the  high-level  represented,  inn  and 
directly  access  the  desired  records  without  se-nefa  usinf  the  low- 
level  representation.  This  has  the  effect  of  building  an  index  for 
an  arbitrary  set  on  the  fly  and  using  it  to  speed  up  subsequent 
accesses  to  the  same  set. 
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Pith  regard  to  the  data  processing  routines  themselves,  there 
is  an  interesting  relationship  to  syntactic  quantif ication.  There 
is  a  direct  semantic  connection  between  the  category  specif ication 
employed  by  the  processes  on  certain  types  of  quantification. 
Consider  the  request  “How  many  salesmen  are  over  100  percent  of 
quota  in  each  region?"  The  quantification  "in  each  region" 
semantically  defines  the  categories  to  be  employed  by  the  counting 
process.  This  gives  an  interesting  simplified  representation  for 
this  kind  of  quantification. 
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Jonclusion 

Vie  have  summarized  the  results  of  the  OMR  supported  research 
on  natural  language  database  query.  It  is  interesting  to  note  the 
change  in  expectations  about  datahase  query  that  have  taken  olace 
luring  the  life  of  this  research  contract.  At  the  outset,  people 
regarded  practical  natural  language  systems  as  a  futuristic 
notion*  something  that  would  not  be  available  for  10-20  years,  l'he 
current  atmosphere  is  one  in  which  a  few  real  world  applications 
are  Just  making  it  into  actual  production. 

It  is  fair  to  say  that  the  issues  considered  most  important 
at  the  outset  of  this  research  (the  natural  language  analysis)  is 
no  longer  the  limiting  factor.  As  is  evident  from  the  discussion 
given  in  this  report,  the  navigational  and  processing  functions 
provide  the  most  fertile  ground  for  future  research.  As  such,  the 
problem  of  providing  practical  natural  language  access  to 
database  is  no  longer  to  be  considered  a  primarily  natural 
language  analysis  problem,  but  also  a  theoretical  database 
problem  with  overtones  of  automatic  programming.  For  this  reason, 
it  is  not  likely  that  more  sophisticated  parsing  techniques  will 
impact  current  capabilities  as  much  as  more  general  AI  research 
related  to  database  semantics  is  likely  to  do. 


